-
-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to TypeScript #1
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of nits, otherwise LGTM.
I've included #2 here as well, why not |
Co-Authored-By: Erik Marks <[email protected]>
Co-Authored-By: Mark Stacey <[email protected]>
Co-Authored-By: Mark Stacey <[email protected]>
Alrighty, I think this is good now. 100% test coverage, I've double-checked the package contents, and the CI is running. |
$ tar tvf metamask-safe-event-emitter-v1.0.1.tgz drwxr-xr-x 0 0 0 0 12 Feb 17:21 package -rw-r--r-- 0 0 0 481 21 Jan 18:04 package/README.md -rw-r--r-- 0 0 0 182 12 Feb 16:54 package/index.d.ts -rw-r--r-- 0 0 0 2115 12 Feb 16:54 package/index.js -rw-r--r-- 0 0 0 1867 12 Feb 16:54 package/index.js.map -rw-r--r-- 0 0 0 885 12 Feb 17:22 package/package.json
Co-Authored-By: Mark Stacey <[email protected]>
throw er; // Unhandled 'error' event | ||
} | ||
// At least give some kind of context to the user | ||
const err = new Error('Unhandled error.' + (er ? ' (' + er.message + ')' : '')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: This might be more readable using a string template?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seconded, but non-blocking.
safeApply(handler, this, args); | ||
} else { | ||
const len = handler.length; | ||
const listeners = arrayClone(handler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually.... this is the only place where arrayClone
is used, and it's entirely pointless? It makes a shallow clone, then discards it. The listeners
array is never touched after this point - just listeners[i]
, which is the same as handler[i]
because shallow. So arrayClone
can be removed altogether.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh - apparently this is in the Gozala/events
module as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's also in node core. It was added here: nodejs/node#601
I must be missing something 🤔 I don't understand why that clone is happening at all, and from skimming through the discussion they don't mention it at all. Maybe some kinda obscure micro-optimization 🤷♂ .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah even @rekmarks' suggestions above, I assume they were all micro-optimizations in (what could be) hot code paths. I left in the len
variable here for that reason. A part of me wants to clean everything up and just say "let the runtime deal with it," but... yeah. 🤷♂
That was 5 years ago, and runtimes have come a long way since. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was poking around on jsperf for that but couldn't find anything conclusive. The good news is, it's definitely fine, and there's no reason to block on it. I don't see any reason not to do [ ...handler ]
, but 🤷♂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out the clone is necessary 🤦♂ . Kinda obvious in retrospect - the clone happens here because the event handlers might subscribe new handlers, or unsubscribe them, thus mutating the handlers array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
safeApply(handler, this, args); | ||
} else { | ||
const len = handler.length; | ||
const listeners = arrayClone(handler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was poking around on jsperf for that but couldn't find anything conclusive. The good news is, it's definitely fine, and there's no reason to block on it. I don't see any reason not to do [ ...handler ]
, but 🤷♂
throw er; // Unhandled 'error' event | ||
} | ||
// At least give some kind of context to the user | ||
const err = new Error('Unhandled error.' + (er ? ' (' + er.message + ')' : '')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seconded, but non-blocking.
This PR, basically, migrates the project to use TypeScript. I've mixed in a few extra (read: too many) changes here because I'm lazy. 🤦♂
We've got:
npm
toyarn
.nvmrc
file@metamask
npm scopeevents
dependency (is this needed?)I'm hoping this can serve as a reference for future migrations and that these configurations (i.e. ESLint & tsconfig) can be factored out as appropriate.